ProtectToolkit-C model

The model for ProtectToolkit-C is based on standard PKCS#11 processing. ProtectToolkit-C running in hardware mode is depicted below to show how an application sends requests to a token via the PKCS#11 interface.

The ProtectToolkit-C model

Slots and tokens

In the PKCS#11 model, a slot represents a device interface and a token represents the actual cryptographic device. For example, a smart card reader would represent a slot and the smart card would represent the token.

ProtectToolkit-C supports the following three types of slots:

• User slots

• Smart card slots

• Admin slot

User slots

User slots are created by the Administrator for use with applications. Each slot automatically holds a User token. All cryptographic mechanisms are supported with these tokens. The system is configurable such that any number of User slots can be created. It is also possible to specify the security policy setting for these slots.

In the default configuration, a single User slot is available. The Administrator can add more slots as required for the local configuration. HSM performance degrades as the number of slots increases. Creating too many slots may cause unacceptable performance. To ensure reasonable performance, it is recommended that you create no more than 200 slots.

Smart card slots

Smart card slots are automatically created and configured for each smart card reader attached to the HSM's external serial ports. The smart card tokens can be used for storage of data objects. Their primary purpose is key backup and restoration. To protect objects stored on the token from unauthenticated access, these objects can be PIN-protected. The smart card slots do not support cryptographic operations.

When a supported smart card token is inserted into a configured smart card slot, it will become available to the ProtectToolkit-C system. New smart card tokens are blank and require initialization before use. The storage format and layout of files on the tokens is proprietary and can store a maximum of 5 objects (up to the storage capacity of the actual token). Objects can be deleted; however, the storage allocated to the object is not reclaimed until the token is re-initialized by the Security Officer or Administrator.

Admin slot

The Admin slot is designated for the administrator and is used for configuration and administration of the HSM. There is only one Admin slot for each HSM.

The Admin slot holds the Admin token and it is on this token that the administration objects reside. For more information about administration objects, see Administration objects.

PKCS#11 objects

As shown in The ProtectToolkit-C model, each token may contain a number of objects. The PKCS#11 standard allows for these different types of objects:

• Data objects, which are defined by an application

• Certificate objects, which represent digital certificates such as X.509

• Key objects, which can be public, private or secret cryptographic keys

Each object in the system is comprised of a number of attributes. These attributes describe the actual object as well as the access policy for that object. For example, each object may be classified as public or private; this classification determines who can access the object. A public object is visible to any user (or application), whereas a private object is only visible once the user is authenticated to the token where that object is stored.

For a complete description of the object attributes, refer to PKCS#11 attributes.

Administration objects

In addition to the object classes defined within PKCS#11, ProtectToolkit-C introduces a new set of objects known as administration objects.

The administration objects represent the hardware and contain HSM configuration settings. They can be queried by the application and some can be modified by an administrator. The default administration objects are automatically created when ProtectToolkit-C initializes.

The administration objects reside on a special token referred to as the Admin token. This token has a fixed security policy. The Admin token resides only in the Admin slot on the HSM.

User roles

As part of the ProtectToolkit-C configuration process, different user roles are assigned to those responsible for the application’s administration and use.

For ProtectToolkit-C there are four defined roles available. These are:

• Security Officer (SO)

• Token Owner or User

• Administration Security Officer (ASO)

• Administrator

Standard PKCS#11 defines the first two of these, the Security Officer (SO) and the Token Owner or User. Each slot and its associated token will have an SO and a User, each with their own respective PINs.

• SOs grant and revoke access to tokens, and assist with key backups.

• Token Owners use tokens for the applications.

Two additional roles are defined that are only available on the Admin token. The holders of these roles handle HSM-level administration and management. These are the Administration Security Officer (ASO) and the Administrator. These roles effectively mirror their standard PKCS#11 counterparts.

PINs and passwords

• User PINs are case-sensitive.

• All PINs, with the exception of smart card PINs, must be:

  • 4 to 32 characters in length, if you are using a firmware version older than ProtectServer 3 HSM Firmware 7.03.00.

  • 8 to 32 characters in length, if you are using ProtectServer 3 HSM Firmware 7.03.00 or newer with the FIPS Algorithms Only security flag set. For more information about this flag, refer to FIPS Algorithms Only.

• PIN characters or asterisks (*) do not appear on screen while the PIN is being typed.

• A brute-force search of PINs can be stopped using one of the following two approaches:

  • Prevent logging in after a certain number of PIN failures.

  • Enforce a time-delay between login attempts after a certain number of PIN failures.

    The time-delay approach is used for ProtectToolkit-C implementations utilizing the ProtectServer Network HSM.

    After the third failed PIN presentation, the device imposes a delay (lengthening in increments of 5 seconds) before the next presented PIN is checked, as shown below:

    • third failed attempt = delay of 5 seconds

    • fourth failed attempt = delay of 10 seconds

    • fifth failed attempt = delay of 15 seconds

    • and so on

  If a PIN presentation occurs before the delay period has expired, the attempt fails with an error indicating that the PIN is locked.